Method and system for implementing third-party authentication based on gray list

ABSTRACT

The present invention relates to a communication method, comprising: receiving a service request from a requesting party; performing a third-party authentication on the service request according to a gray list and obtaining an authentication result; and processing the service request according to the authentication result. The present invention relates to a communication system, comprising: means for receiving a service request from a requesting party; means for performing a third-party authentication on the service request according to a gray list and obtaining an authentication result; and means for processing the service request according to the authentication result. The present invention implements a third-party control of services based on the gray list, and can effectively manage a variety of services in the communication system.

FIELD THE INVENTION

The present invention relates to a communication system, and morespecifically, to a method and system using a gray list for third-partyauthentication in the communication system.

BACKGROUND OF THE INVENTION

Currently, white lists and black lists are widely used technology, whichindicates a corresponding service request should be allowed or denied.For white lists and black lists, the behaviors of a system arepredefined, whereby the white Lists and black lists can be seen aspredefined rules. In reality, the white list and black list rules areapplied to a lot of systems or services, such as, operating system,firewall, antivirus software, mail systems, application software, voicecall, data communications, data storage, etc. In general, the white listand black list rules are applied to almost all of the applicationsinvolving control. If a white list is established, then only users (orIP address, IP packet, mail, etc.) in the white list can obtain thegrant of the system to get system services. For example, if a white listis established in a mail system, then mails of users in the white listwill pass with priority, and will not be rejected as spam, withincreasing security and convenience. If a black list is established,then users (or IP address, IP packet, e-mail, virus, etc.) listed in theblack list cannot obtain the grant of the system. For example, in acommunication operating system, if a certain user (for example, theuser's identifier) is listed in a black list, then it may not be able toget a certain service or all services.

In the prior art, as in IP Multimedia Subsystem shown in FIG. 1, thesystem includes: User Equipment (UE), Proxy Call Session ControlFunction (PCSCF), Service Call Session Control Function (SCSCF) andApplication Server (AS). User Equipment UE sends INVITE message M1 toPCSCF to initiate a service request. PCSCF sends INVITE message M2 toSCSCF, and then SCSCF sends INVITE message M3 to the AS. ApplicationServer AS checks the white or black list, sends to the User Equipment aresponse which agrees to provide the service if the User Equipment is inthe white list, and sends to the User Equipment a response which refusesto provide the service if the User Equipment is in the black list.

In reality, for certain types of services, whether the services shouldbe provided is determined by the circumstances dynamically. Especiallyin the IP Multimedia Subsystem, which can offer various services inaddition to traditional phone calls, such as, video sharing, unifiedmessaging, unified communication, click-to-conference, multimediacollaboration kits, multiplayer game, friend and relative tracking,virtual PBX, security monitoring, outdoor work team efficiency,multimedia ring back tones, call shield, multimedia calleridentification, intelligent call center routing, find-tracking andgrouping search, or paid by a third party (the authenticating party),etc. For the above service request, sometimes, it is hard to meetrequirements only to use the white and black lists to control. Forexample, in an instance needing service control by a third party, thewhite and black lists cannot implement third-party control of theservices, and cannot implement real-time control of the services.

The latest practice has proposed a gray list between the black list andthe white list. The gray list can intelligently perform service control,for example, it can intercept most of the spam. The gray list requiresthe service requesting party to re-send the just sent service request.For example, in an e-mail application, it requires the e-mail sender towait a few minutes (the specific time can be set by the systemautomatically or by the administrator manually) before re-sending oncethe just sent e-mail. The gray list is based on the fact that themajority of service requests sent in the form of broadcast is usuallysent only once, ignoring the request asking to re-send the servicerequests after a certain time interval. All service requests that areoriginally rejected by the application server and are required to be“later re-sent” will enter a gray list filter. If after 10 minutes (thespecific time can be set by the system automatically or by theadministrator manually), the service request is sent again by a remoteserver, it will pass without any obstacle, and thereafter a requestconsistent with this request sender will also pass smoothly.

However, the way hereinabove still has a problem that when a maliciousattacker sends a service request again after a specified time, such as10 minutes, then the system will put the malicious attacker into thewhite list, so that the system is still unable to accurately determinewhether to provide the service to an unknown service requester.Moreover, when the requested service of the requester needsauthentication from a third party, for example, the service is managedby a third party, the white and black lists cannot implement third-partyauthentication.

SUMMARY OF THE INVENTION

In order to solve the above problems, the present invention implementsthird-party authentication based on a gray list, and provides a method,system and computer program product.

According to a first aspect, the present invention provides acommunication method, characterized in that, the method comprises:

receiving a service request from a requesting party;

performing a third-party authentication on the service request accordingto a gray list and obtaining an authentication result; and

processing the service request according to the authentication result.

Wherein, the gray list includes at least the following three attributes:requesting party, authenticating party and service.

Wherein, performing the third-party authentication on the servicerequest according to a gray list comprises: forwarding the servicerequest from the requesting party to the authenticating party whichauthenticates the service request.

Wherein, processing the service request according to the authenticationresult comprises: providing the service to the requesting party when theauthentication result is Accept; and not providing the service to therequesting party when the authentication result is Reject.

Preferably, when the service is not provided to the requesting party, areject message is sent to the requesting party, in which a reject reasonis described.

There is further comprised dynamically updating the gray list accordingto a request of the authenticating party.

Wherein, performing the third-party authentication on the servicerequest according to a gray list comprises: performing an authenticationof different service level on the service request.

Wherein, performing the third-party authentication on the servicerequest according to a gray List comprises: performing an authenticationon the service request by one or more third parties.

According to a second aspect, the present invention provides acommunication system, characterized in that, the system comprises:

means for receiving a service request from a requesting party;

means for performing a third-party authentication on the service requestaccording to a gray list and obtaining an authentication result; and

means for processing the service request according to the authenticationresult.

Wherein, the gray list includes at least the following three attributes:requesting party, authenticating party and service.

Wherein, means for performing the third-party authentication on theservice request according to a gray list and obtaining an authenticationresult comprises: means for forwarding the service request from therequesting party to the authenticating party which authenticates theservice request.

Wherein, means for processing the service request according to theauthentication result comprises: means for providing the service to therequesting party when the authentication result is Accept; and means fornot providing the service to the requesting party when theauthentication result is Reject.

Preferably, when the service is not provided to the requesting party, areject message is sent to the requesting party, in which a reject reasonis described.

There is further comprised means for dynamically updating the gray listaccording to a request of the authenticating party.

Wherein, means for performing the third-party authentication on theservice request according to a gray list and obtaining an authenticationresult comprises: means for performing an authentication of differentservice level on the service request.

Wherein, means for performing the third-party authentication on theservice request according to a gray list and obtaining an authenticationresult comprises: means for performing an authentication on the servicerequest by one or more third parties.

According to a third aspect, the present invention provides acommunication method, characterized in that, the method comprises:

receiving a service request from a calling party;

performing an authentication on the service request according to a graylist and obtaining an authentication result; and

processing the service request according to the authentication result.

According to a fourth aspect, the present invention provides a computerprogram product comprising computer program codes stored on acomputer-readable storage medium, which executes when the computerprogram codes are executed on a processor:

receiving a service request from a requesting party;

performing a third-party authentication on the service request accordingto a gray list and obtaining an authentication result; and

processing the service request according to the authentication result.

Gray list is a new concept in telecommunication area, which can bewidely used for various services that need third-party authentication.For example, parents can control web access for children in real time; aboss can control if an employee can access certain database/service/datain real time, etc. Although a black list can also be used in control,the black list cannot implement real-time control.

BRIEF DESCRIPTION OF TIFF DRAWINGS

The disclosed subject matter may be understood by reference to thefollowing description in conjunction with the drawings, wherein the samereference signs denote the same elements, and wherein:

FIG. 1 shows a timing diagram of a service control according to a whitelist and a black list in the prior art;

FIG. 2 shows a timing diagram of a third-party authentication using agray list according to an embodiment of the invention;

FIG. 3 shows a timing diagram of a third-party authentication using agray list according to another embodiment of the invention;

FIG. 4 shows a timing diagram of a third-party authentication using agray list according to yet another embodiment of the invention;

FIG. 5 shows a timing diagram of a third-party authentication using agray list according to yet another embodiment of the invention; and

FIG. 6 shows a flow chart of a method for implementing third-partyauthentication based on the gray list according to a preferredembodiment of the invention.

Although the disclosed theme is likely to have various modifications andalternative forms, specific embodiments thereof have been described indetail herein and shown in examples in the drawings. However, it shouldbe understood that the description of the specific embodiments herein isnot to limit the disclosed theme to the disclosed particular form, andon the contrary, the present invention covers all modifications,equivalence and alternatives that fall within the scope of the appendedclaims.

DETAILED DESCRIPTION OF THE INVENTION

Exemplary embodiments for carrying out the invention are described nowby reference to the drawings. However, the invention may be performed invarious forms, not limited to the embodiments described herein. Theseembodiments are provided for extensively and comprehensively disclosingthe invention, and for sufficiently conveying the extent of theinvention to those skilled in the art. Terms in exemplary modes forcarrying out the invention illustrated in the drawings do not define theinvention. In the figures, identical units/elements are represented byidentical reference signs.

Detailed exemplary modes for carrying out the invention are disclosedhere. However, the specific constructions and function details disclosedhere are only for the purpose of the typical description of theexemplary implementation of the invention. However, the presentinvention can be embodied in a variety of alternative forms and shouldnot be constructed to be limited to implementations as set forth herein.Therefore, although the exemplary modes for carrying out the inventionmay have various modifications and substitutions, the specific modes forcarrying out the invention therein are shown through examples in thedrawings and will be described in detail here. However, it should beunderstood that it is not intended to limit the exemplary modes forcarrying out the invention to the disclosed particular form; while onthe contrary, the exemplary modes for carrying out the invention willcover all modifications, equivalence, and options that fall within thescope of the invention.

Unless otherwise stated, “a”, “one”, “said” and “the” used herein alsoinclude plural. In addition, it should be understood that terms used inthe description, “include”, “comprise” and/or “contain”, specify somefeatures, entities, steps, operations, units, and/or elements, but donot exclude one or more features, entities, steps, operations, units,elements and/or their groups. It should be understood that, when a unitis referred to being “connected” or “coupled” to another unit, it may bedirectly connected or coupled to another unit, or there may he anintermediate unit. In addition, the “connection” or “coupling” hereinincludes a wireless connection or coupling. The term “and/or” usedherein includes any combination of and all combinations of one or moreof the listed related items.

Unless otherwise stated, terms used herein (including scientific andtechnical terms) have common meaning generally understood by thoseskilled in the art. In addition, it can be appreciated that a termdefined by a commonly used dictionary should be construed to have ameaning consistent with the context in the related are and should not beconstrued as an idealized or overly formal meaning.

FIG. 2 shows a timing diagram of a third-party authentication using agray list according to an embodiment of the invention. For anillustrative purpose, an IP Multimedia Subsystem is described here as anexample, and those of ordinary skill in the art should appropriate thatthe present invention can be applied to other communication systems. Asshown in FIG. 2, the system includes: Proxy Call Session ControlFunction (PCSCF), Service Call Session Control Function (SCSCF),Application Server (AS), and User Equipment A (UE A) and User EquipmentB (UE B).

In one preferred embodiment, a third-party authentication is implementedvia a gray list in IMS. In IMS, besides voice service, there are a largenumber of additional services which play an important role. In onepreferred embodiment, it is also very important to implement the controlof the services in IMS. Preferably, the application server AS definesthe gray list. The gray list is a predefined rule determined by theapplication server, and the gray list (or predefined rule) definestherein by which authenticating party a requested service of arequesting party should be authenticated. Preferably, the gray list (orpredefined rule) may be one or more triples. In the present embodiment,the triple includes three attributes: requesting party, authenticatingparty, and service. Those of ordinary skill in the art shouldappropriate that the triple may also include more attributes. Wherein,the requesting party is the party initiating a service request; theauthenticating party is a third party performing authentication on theabove service request, and the authenticating party can determinewhether to provide a certain service to a certain requesting party. Forexample, in FIG. 2, UE A is the requesting party and UE B is theauthenticating party. The service may be: video sharing, unifiedmessaging, unified communication, click-to-conference, multimediacollaboration kit, multiplayer game, friend and relative tracking,virtual PBX, security monitoring, outdoor work team efficiency,multimedia ring back tones, call shield., multimedia calleridentification, intelligent call center routing, find-tracking andgrouping search, or paid by a third party (the authenticating party),etc.

For the sake of clarity, FIGS. 2-5 simplify call flow in IMS, i.e.,remove ACK messages and the like from the session. In addition, FIGS.2-5 simplify some other equipments in IMS, and interrogating CallSession Control Function (ICSCF), Home Subscriber Server (HSS), DomainName Server (DNS) and the like in the figures are not described.

In the preferred embodiment, as shown in FIG. 2, User Equipment A sendsINVITE message M1 to PCSCF to initiate a service request. Preferably,the service request can be included in the INVITE message. PCSCF sendsINVITE message M2 to SCSCF, and then SCSCF sends INVITE message M3 tothe application server. Upon receipt of the service request, theapplication server AS first determines the requesting party of theservice request. In the present embodiment, the application server ASdetermines that the service requesting party is User Equipment A. Here,a variety of symbols, identifiers, etc. can be used to identify UserEquipment A. The application server AS searches the gray list for UserEquipment A. In the present embodiment, the gray list (or predefinedrule) is one or more triples, the triple comprising at least threeattributes, i.e., requesting party, authenticating party, and service.Preferably, the gray list (or predefined rule) can be expressed as atriple <Requesting Party, Authenticating Party, Service>. In the presentembodiment, the requesting party in the gray list is User Equipment A,the authenticating party is User Equipment B, and the service is videosharing. Therefore, the gray list can be expressed as <User Equipment A,User Equipment B, Video Sharing>.

In one embodiment, when performing a search according to User EquipmentA and/or video sharing, the application server obtains a gray list <UserEquipment A, User Equipment B, Video Sharing>. In a preferredembodiment, the gray list may be stored on or outside the applicationserver. In a preferred embodiment, the gray list may be stored in adatabase, or can be stored in a way of a file system and the like. Thegray list indicates that an authentication from User Equipment B isneeded when the service requested by User Equipment A is video sharing.

In a preferred embodiment, the application server puts the servicerequest into INVITE message M4, and sends INVITE message M4 to UserEquipment B. In another preferred embodiment, the application serverforwards INVITE message M4 and SIP message header or parameters (e.g.,SERVICE_TYPE=VIDEO SHARING, REQUEST_UE=UE A) to User Equipment B. TheUser Equipment B receives INVITE message M4, extracts the servicerequest therein and performs third-party authentication according to theservice request. Alternatively, User Equipment B receives INVITE messageM4 and SIP message header or parameters, extracts the service request inthe SIP message header or parameters, and performs third-partyauthentication according to the service request. In the preferredembodiment, if User Equipment B decides to accept the service request,it sends answer message M5, which indicates to accept the service, tothe application server, and then the application server provides theservice to User Equipment A; if User Equipment B decides to reject theservice request, it sends answer message M5, which indicates to rejectthe service, to the application server, and then the application serverrefuses to provide the service to User Equipment A.

FIG. 3 shows a timing diagram of a third-party authentication using agray list according to another embodiment of the invention. In onepreferred embodiment, the gray list of the present invention can includea white list and a black list. For example, when the authenticatingparty in the gray list which comprises requesting party, authenticatingparty and service is “NULL”, it means there is no authenticating party.When the gray list comprises only requesting party and service, that isto say, the authenticating party is “NULL”. It means there is no needfor any third-party authentication. For example, when the gray list isexpressed as <User Equipment A, NULL, Video Sharing>, the applicationserver can provide the video sharing service to User Equipment A,without the need for the third-party authentication. At this point, UserEquipment A is in the white list for the video sharing service. As itcan be seen, the gray list of the present invention can include a whitelist.

When the gray list is <User Equipment A, NULL, Forbid Video Sharing>,the application server does not provide the video sharing service toUser Equipment A, without the need for a third-party authentication. Atthis point, User Equipment A is in the black list for the video sharingservice. As it can be seen, the gray list of the present invention caninclude a black list.

Further, when the gray list is expressed as <User Equipment A, NULL, AllServices>, the application server can provide all services to UserEquipment A, without the need for a third-party authentication. At thispoint, User Equipment A is in the white list for all services. When thegray list is expressed as <User Equipment A, NULL, Forbid All Services>,the application server does not provide any service to User Equipment A,without the need for a third-party authentication. At this point, UserEquipment A is in the black list for all services. In addition, the graylist may also be expressed as <User Equipment A, NULL, Service Set 1>,<User Equipment A, NULL, Service Set 2>, etc., which means theapplication server can provide services in service set 1, service set 2and the like to User Equipment A, without the need for a third-partyauthentication. Further, the gray list may also be expressed as <UserEquipment A, NULL, Forbid Service Set 1>, <User Equipment A, NULL,Forbid Service Set 2>, etc., which means the application server canrefuse to provide services in service set 1, service set 2 and the liketo User Equipment A, without the need for a third-party authentication.

FIG. 4 shows a timing diagram of a third-party authentication using agray list according to yet another embodiment of the invention. The graylist according to the present invention supports authenticationincluding multiple third parties. In many cases, the service request ofthe requesting party needs authentication from multiple third parties,and thus the gray list must support a multiple-third-partyauthentication. Preferably, multiple triples in the gray list may beused to implement multiple-third-party authentication. When UserEquipment A requests for video sharing service, the application serverretrieves multiple triples, such as <User Equipment A, User Equipment B,Video Sharing>, <User Equipment A, User Equipment C, Video Sharing> . .. <User Equipment A, User Equipment N, Video Sharing>, and then theapplication server should forward the service request to the abovemultiple third parties, respectively, i.e., User Equipment B, UserEquipment C, . . . User Equipment N. The third-party authentication ofvideo sharing service request by User Equipment A is performed by theabove multiple third parties.

According to a preferred embodiment, in the case of themultiple-third-party authentication, only when all the third partiesaccept the service request of the requesting party, the applicationserver provides the service to the requesting party. For example, onlywhen all the above User Equipments B to N agree to provide the serviceto User Equipment A, the application server provides the service to UserEquipment A. Alternatively, once any one of the third parties acceptsthe service request of the requesting party, the application server mayprovide the service to the requesting party. For example, once any oneof the above User Equipments B to N agrees to provide the service toUser Equipment A, the application server may provide the service to UserEquipment A. Further, the authenticating party or the application serversystem may configure that when M (M is less than the total number ofUser Equipments of the authenticating parties) of all third partiesaccept the service request of the requesting party, the applicationserver can provide the service to the requesting party. For example,when M (M is less than the total number of User Equipments forauthenticating) of the above User Equipments B to N agree to provide theservice to User Equipment A, the application server can provide theservice to User Equipment A.

In a preferred embodiment, the authenticating party may send a requestto add one or more authenticating parties, thereby implementing dynamicupdate of the gray list. For example, User Equipment B sends a requestto the application server to add an authenticating party for the videosharing service of User Equipment A, for example, User Equipment C.Then, a triple <User Equipment A, User Equipment C, Video Sharing> isadded into the gray list of the application servers. Thus, when UserEquipment A initiates a video sharing service request to the applicationserver, the application server forwards the service request to UserEquipment B and User Equipment C.

FIG. 5 shows a timing diagram of third-party authentication using a graylist according to yet another embodiment of the invention. The gray list(or predefined rule) of the present invention includes, but not limitedto, the following attributes: requesting party, authenticating party,and service. Preferably, the gray list (or predefined rule) may be oneor more tetrads. In the present embodiment, the tetrad consists of fourattributes: requesting party, authenticating party, service and servicelevel. Wherein, the requesting party is the party initiating a servicerequest; the authenticating party is a third party performingauthentication on the above service request, and the authenticatingparty can determine whether to provide a certain service to a certainrequesting party. For example, in FIG. 5, UE A is the requesting partyand UE B is the authenticating party. The service may be: video sharing,unified messaging, unified communication, click-to-conference,multimedia collaboration kit, multiplayer game, friend and relativetracking, virtual PBX, security monitoring, outdoor work teamefficiency, multimedia ring back tones, call shield, multimedia calleridentification, intelligent call center routing, find-tracking andgrouping search, or paid by a third party (the authenticating party),etc. The service level is the level of the service provided to therequesting party. Here, the description is made by example of usingdatabase access as the service, but those of ordinary skill in the artshould appropriate that the examples of the service are not limited todatabase access.

In the preferred embodiment, as shown in FIG. 5, User Equipment A sendsINVITE message M1 to PCSCF to initiate a service request. Preferably,the service request can be included in the INVITE message. PCSCF sendsINVITE message M2 to SCSCF, and then SCSCF sends INVITE message M3 tothe application server. Upon receipt of the service request, theapplication server AS first determines the requesting party of theservice request. In the present embodiment, the application server ASdetermines that the service requesting party is User Equipment A. Here,a variety of symbols, identifiers, etc. can be used to identify UserEquipment A. The application server AS searches the gray list for UserEquipment A. In the present embodiment, the gray list (or predefinedrule) is one or more tetrads, the tetrad comprising at least fourattributes, i.e., requesting party, authenticating party, service andservice level. Preferably, the gray list (or predefined rule) can heexpressed as a tetrad <Requesting Party, Authenticating Party, Service,Service Level>. In the present embodiment, the requesting party in thegray list is User Equipment A, the authenticating party is UserEquipment B, the service is database access, and the service levelcomprises read and write. For example, the gray list can he expressed as<User Equipment A, User Equipment B, Database Access, Write>.

In one embodiment, when performing a search according to User EquipmentA and/or database access, the application server may obtain a gray list<User Equipment A, User Equipment B, Database Access, Read>. In anotherembodiment, when performing a search according to User Equipment Aand/or database access, the application server may obtain a gray list<User Equipment A, User Equipment B, Database Access, Write>. In apreferred embodiment, the gray list may be stored on or outside theapplication server in a preferred embodiment, the gray list may bestored in a database, and may also be stored in a way of a file systemand the like. The gray list indicates that when the service requested byUser Equipment A is database access, an authentication from UserEquipment B is needed and User Equipment B may grant database read orwrite by User Equipment A.

In a preferred embodiment, the application server puts the servicerequest into INVITE message M4, and sends INVITE message M4 to UserEquipment B. In another preferred embodiment, the application serverforwards INVITE message M4 and SIP message header or parameters (e.g.,SERVICE_TYPE=DATABASE ACCESS, REQUEST_UE=UE A) to User Equipment B. TheUser Equipment B receives INVITE message M4, extracts the servicerequest therein and performs a third-party authentication according tothe service request. Alternatively, User Equipment B receives INVITEmessage M4 and SIP message header or parameters, extracts the servicerequest therein, and performs third-party authentication according tothe service request.

In the preferred embodiment, if User Equipment B decides to reject theservice request, it sends answer message M5, which indicates to rejectthe service, to the application server, and then the application serverrefuses to provide the service to User Equipment A

In the preferred embodiment, if User Equipment B decides to accept theservice request, it sends answer message M5, which indicates to acceptthe service, to the application server. If the retrieved gray listdefines <User Equipments A, User Equipment B, Database Access, Read>,then the application server can only grant database access by UserEquipment A (i.e., User Equipment A can only read data, but can notmodify, delete or add data). If the retrieved gray list defines <UserEquipment A, User Equipment B, Database Access, Write>, the applicationserver can grant database write by User Equipment A (i.e., UserEquipment A can not only read but also modify, delete or add data).

In a preferred embodiment, the primary/first authenticating party maysend a request to delete/modify one or more other authenticating partiesin the gray list non-primary/first authenticating parties). For example,the requesting party is User Equipment A, and the authenticating partiesare User Equipments B, C and D, wherein User Equipment B is theprimary/first authenticating party. User equipment B can send a requestto delete User Equipment C so that the authenticating parties change toUser Equipments B and D. Also, User Equipment B can send a request tochange User Equipment C to User Equipment E so that the authenticatingparties change to User Equipments B, D and E.

In a preferred embodiment, the primary/first authenticating party maysend a request to modify service levels that can be granted by otherauthenticating parties (i.e., non-primary/first authenticating parties)in one or more gray lists. For example, the requesting party is UserEquipment A, and the authenticating parties are User Equipments B and C,the service is database access, and the service level includes read andwrite, wherein. User Equipment B is the primary/first authenticatingparty. The gray list for User Equipment C is <User Equipment A, UserEquipment C, Database Access, Write>. At this point, User equipment Bcan send a request to modify the authorization level of User Equipment Cto “read”, so that the gray list for User Equipment C changes to <UserEquipment A, User Equipment C, Database Access, Read>.

FIG. 6 shows a flow chart of a method of implementing a third-partyauthentication based on the gray list according to a preferredembodiment of the invention. At 601, a service request from therequesting party is received. Wherein, the requesting party is the partyinitiating the service request, and may be personal computer, laptopcomputer, personal digital assistant s and the like. Preferably, therequesting party may be User Equipment A as shown in FIG. 2. UserEquipment A sends INVITE message M1 to PCSCF to initiate the servicerequest. Preferably, the service request can be included in the INVITEmessage. PCSCF sends INVITE message M2 to SCSCF, and then SCSCF sendsINVITE message M3 to the application server.

At 602, a third-party authentication is performed on the service requestaccording to the gray list (predefined rule), and an authenticationresult is obtained. Wherein, the third-party authentication is performedby the authenticating party, which is the third party authenticating theabove service request and can determine whether to provide a certainservice to the requesting party. Upon the receipt of the servicerequest, the application server AS determines the requesting party ofthe service request. The application server AS searches the gray listaccording to the requesting party and/or service name. For example, thegray list <Requesting Party, Authenticating Party, Service> might besearched. The application server puts the service request into INVITEmessage M4 and sends it to the authenticating party. The authenticatingparty receives INVITE message, extracts the service request therein andperforms third-party authentication according to the service request.The authenticating party sends the authentication result to theapplication server. In another preferred embodiment, the applicationserver forwards INVITE message M4 and SIP message header or parametersto the authenticating party.

At 603, the service request is processed according to the authenticationresult. If the authentication result is the authenticating party decidesto accept the service request, it sends answer message, which indicatesto accept the service, to the application server, and then theapplication server provides the service to the requesting party; if theauthentication result is the authenticating party decides to reject theservice request, it sends answer message, which indicates to reject theservice, to the application server, and then the application serverrefuses to provide the service to the requesting party.

Preferably, when the authenticating party in the gray list is “NULL”, itmeans there is no need for any third-party authentication. For example,when the gray list is expressed as <User Equipment A, NULL, VideoSharing>, the application server can accept/reject the service requestfrom User Equipment A, without the need for third-party authentication.At this point, the above method becomes a method of non-third-partyauthentication, receiving a service request of a calling party;performing authentication on the service request according to a graylist and obtaining an authentication result; and processing the servicerequest according to the authentication result.

Gray list is a new concept in telecommunication area, which can bewidely used for various services that need third-party authentication.The gray list of the present invention is not limited to the triplecomprising three attributes or the tetrad comprising four attributes,but can be expanded to a multi-tuple comprising more attributesaccording to needs. The expansion of the gray list may be done accordingto the requirements of the system. The gray list can be widely usedvarious applications of third-party authentication, for example, parentscan control web access for children in real time; a boss can control ifhis employee can access certain database/service/data inn real time,etc. Although a black list can also be used in control, the black listcannot implement real-time control.

Meanwhile, it is noted that, typically, software implementing aspects ofthe disclosed theme is coded in some form of program storage medium, oris performed on some type of transportation medium. The program storagemedium may be magnetic (e.g., floppy disk or hard drive) or optical(e.g., Compact Disk Read Only Memory or “CD-ROM”), and may be read-onlyor random access the transportation medium may be twisted pair, coaxialcable, fiber, or some other appropriate transportation medium in theprior art. The disclosed theme is not limited to these aspects of anygiven implementation. Computer-readable medium with instructions storedthereon, such as DVD, CD-ROM, floppy disk, or memory (for example,non-volatile memory) is further provided, and steps of the above methodare executed when the instructions are executed by the processor.

The above disclosed specific embodiments are only illustrative, and thedisclosed theme can be modified and implemented in a different butequivalent way that is obvious to those skilled in the art benefitingfrom the teaching herein. In addition, it is not desired to limitdetailed construction or design shown here, but as described by thefollowing claims. It is therefore important that the specificembodiments disclosed hereinabove may be changed or modified, and allchanges are considered to fall within the scope of the disclosed theme.Thus, the scope of protection herein is set forth as in the followingclaims.

1. A communication method executed in an IP multimedia System (IMS)network comprising: receiving a service request from a requesting partyin the IMS network; performing a third-party authentication on theservice request by selecting a first authenticating party in the IMSnetwork according to a gray list and obtaining an authentication result;processing the service request according to the authentication result;receiving a request from the first authenticating party in the IMSnetwork to modify a service level granted to the requesting party; andfurther comprising dynamically updating the gray list according to therequest.
 2. The method according to claim 1, wherein the gray listincludes at least the following three attributes: requesting party,authenticating party and service.
 3. The method according to claim 1,wherein performing the third-party authentication on the service requestby selecting a first authenticating party in the IMS network accordingto a gray list comprises: forwarding the service request from therequesting party to the first authenticating party which authenticatesthe service request.
 4. The method according to claim 2, whereinprocessing the service request according to the authentication resultcomprises: providing the service to the requesting party when theauthentication result is Accept; and not providing the service to therequesting party when the authentication result is Reject.
 5. (canceled)6. The method according to claim 1, wherein, performing the third-partyauthentication on the service request by selecting a firstauthenticating party in the IMS network according to a gray listcomprises: performing an authentication of different service level onthe service request.
 7. (canceled)
 8. A communication system including anon-transitory computer-readable storage device storingcomputer-executable instructions which, when executed by a processor ofa computing device in an IP Multimedia System (IMS) network, configurethe processor to: receive a service request from a requesting party inthe IMS network; perform a third-party authentication on the servicerequest by selecting a first authenticating party in the IMS networkaccording to a gray list and obtaining an authentication result; processthe service request according to the authentication result; modify aservice level granted to the requesting party in response to a requestfrom the first authenticating party in the IMS network; wherein theprocessor is further configured to dynamically update the gray listaccording to the request.
 9. The system according to claim 8, whereinthe gray list includes at least the following three attributes:requesting party, authenticating party and service.
 10. The systemaccording to claim 9, wherein the processor is further configured toperform the third-party authentication on the service request byforwarding the service request from the requesting party to theauthenticating party which authenticates the service request.
 11. Thesystem according to claim 8, wherein the processor is further configuredto process the service request according to the authentication resultby: providing the service to the requesting party when theauthentication result is Accept; and not providing the service to therequesting party when the authentication result is Reject. 12.(canceled)
 13. The system according to claim 8, wherein the processor isfurther configured to perform third-party authentication on the servicerequest according to a gray list and obtain an authentication result byperforming an authentication of different service level on the servicerequest.
 14. (canceled)
 15. A communication method executed in anapplication server in an IP Multimedia System (IMS) network, the methodcomprising: receiving a service request from a calling party in the IMSnetwork; performing an authentication on the service request byselecting a first authenticating party in the IMS network according to agray list and obtaining an authentication result; processing the servicerequest according to the authentication result; modifying a servicelevel granted to the calling party in response to a request from thefirst authenticating party in the IMS network; and further comprisingdynamically updating the gray list according to the request.
 16. Themethod according to claim 1, wherein performing the third-partyauthentication on the service request according to a gray listcomprises: forwarding the service request from the requesting party tothe first authenticating party and to one or more additionalauthenticating parties which each authenticate the service request. 17.The method according to claim 16, wherein processing the service requestaccording to the authentication result further comprises processing theservice request when all of authentication parties have authenticatedthe service request.
 18. The method according to claim 16, whereinprocessing the service request according to the authentication resultfurther comprises processing the service request when any one ofauthentication parties have authenticated the service request.
 19. Themethod according to claim 16, wherein processing the service requestaccording to the authentication result further comprises processing theservice request when at least two authentication parties haveauthenticated the service request.
 20. The method according to claim 8,wherein the processor is further configured to perform the third-partyauthentication on the service request according to a gray list byforwarding the service request from the requesting party to the firstauthenticating party and to one or more additional authenticatingparties which each authenticate the service request.
 21. The methodaccording to claim 20, wherein the processor is further configured toprocess the service request according to the authentication result byprocessing the service request when all of authentication parties haveauthenticated the service request.
 22. The method according to claim 20,wherein the processor is further configured to process the servicerequest according to the authentication result by processing the servicerequest when any one of authentication parties have authenticated theservice request.
 23. The method according to claim 20, wherein theprocessor is further configured to process the service request accordingto the authentication result by processing the service request when atleast two authentication parties have authenticated the service request.24. The method according to claim 15, wherein performing anauthentication on the service request by selecting a firstauthenticating party in the IMS network according to a gray listcomprises: forwarding the service request from the calling party to thefirst authenticating party which authenticates the service request. 25.The method according to claim 15, wherein the gray list includes atleast the following three attributes: calling party, authenticatingparty and service; and processing the service request according to theauthentication result comprises providing the service to the callingparty when the authentication result is Accept; and not providing theservice to the calling party when the authentication result is Reject.26. The method according to claim 15, wherein performing theauthentication on the service request according to a gray listcomprises: forwarding the service request from the calling party to thefirst authenticating party and to one or more additional authenticatingparties which each authenticate the service request.